feat(registration): broaden registration readiness and config signals - #73
Merged
Merged
Conversation
JSONbored
requested changes
May 30, 2026
JSONbored
left a comment
JSONbored
left a comment
Owner
There was a problem hiding this comment.
@Khaostica this needs policy corrections before merge.
Required:
- Resolve the conflict in
src/api/routes.ts. - Do not treat disabled check runs as a registration-readiness warning; Gittensory intentionally defaults public checks off.
- Fix config math: do not subtract
issueDiscoverySharefromemissionShare; emissions are assigned externally and issue-discovery share is repo config semantics. - For Gittensory-specific recommendations, keep direct-PR-first posture and support the intended 30% maintainer cut when readiness is met.
JSONbored
requested changes
Jun 1, 2026
JSONbored
left a comment
JSONbored
left a comment
Owner
There was a problem hiding this comment.
@Khaostica The feature direction is still reasonable, and CI is green, but this cannot be merged in its current state.
A few notes:
- Broadening registration readiness and config signals is useful, especially if the route stays aligned with the current API/OpenAPI structure.
- The branch is currently conflicted with
src/api/routes.ts. - Because current
mainhas moved substantially in the app/API surfaces, I do not want to approve the old route shape through a conflict. The conflict needs to be resolved first so the reviewed code matches what would actually land.
Required changes:
- Rebase onto current
mainand resolve thesrc/api/routes.tsconflict. - Confirm the registration-readiness response still matches the current API and OpenAPI conventions.
- Re-run validation after the rebase.
Expected validation:
npm run typechecknpm run test:coverage
Rebased onto current main and resolved the src/api/routes.ts conflict so
the reviewed code matches what would actually land. The route now delegates
to pure, unit-tested signal builders instead of inline logic.
- Add src/signals/registration-readiness.ts with two pure builders:
- buildRegistrationReadiness(): direct-PR readiness, issue-discovery
readiness, label policy (incl. trusted-pipeline), maintainer-cut
readiness, test-gate health, queue health, contribution docs, and
GitHub App behavior (install state, quiet-by-default, missing
permission/event warnings).
- buildGittensorConfigRecommendation(): initial config recommendation
with issueDiscoveryShare, label multipliers, maintainerCut, linked-issue
policy, explicit tradeoffs, reasons, and warnings.
- Reworked GET /v1/repos/:owner/:repo/registration-readiness and
.../gittensor-config-recommendation to delegate to the builders over the
current buildRepoIntelligenceResponse intelligence layer, and load
installation health so the report can describe real GitHub App behavior.
- Config math: directPrShare is the within-repo split (1 - issueDiscoveryShare)
and is not derived from the externally-assigned emissionShare; target a 30%
maintainer cut when readiness is met. Check runs intentionally default off,
so their state is informational in testCoverageHealth, not a warning.
- Extended the RegistrationReadiness and GittensorConfigRecommendation OpenAPI
schemas (and regenerated apps/gittensory-ui/public/openapi.json) to match.
- Added test/unit/registration-readiness.test.ts covering ready/not-ready
repos, issue-discovery-disabled recommendation, maintainer-cut readiness,
missing-labels/docs/test-gate warnings, GitHub App permission/event
warnings, lane variants, and a forbidden-public-language invariant.
Validation: npm run typecheck passes; registration-readiness, api
integration, and openapi suites pass (new builder at 100% lines, 99% branch);
npm run ui:openapi:check passes.
Closes JSONbored#38
Khaostica
force-pushed
the
claude/strange-wright-aa219f
branch
from
June 1, 2026 14:17
b8f292b to
59cc531
Compare
JSONbored
approved these changes
Jun 1, 2026
JSONbored
left a comment
JSONbored
left a comment
Owner
There was a problem hiding this comment.
@Khaostica This is ready from my side. The registration-readiness logic is now centralized in registration-readiness, the API route is mostly response glue, and the tests cover direct/split/issue-discovery policy, disabled public surfaces, config quality, and readiness blockers. Current checks are green and the merge tree is clean.
JSONbored
added
gittensor:bug
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Completes #38 by turning the repo-owner registration-readiness and Gittensor config recommendation into pure, unit-tested signal builders, and broadening the readiness report to evaluate every dimension the issue requires.
Output stays advisory and private/API-first: no public GitHub output, no wallet/hotkey/score exposure.
What changed
src/signals/registration-readiness.tswith two pure builders:buildRegistrationReadiness()— direct-PR readiness, issue-discovery readiness, label policy, maintainer-cut readiness, test-gate health, queue health, contribution docs, and GitHub App behavior (install state, quiet-by-default, missing permission/event warnings).buildGittensorConfigRecommendation()— initial config recommendation withissueDiscoveryShare, label multipliers,maintainerCut, linked-issue policy, explicit tradeoffs, reasons, and warnings.GET /v1/repos/:owner/:repo/registration-readinessand.../gittensor-config-recommendationto delegate to the pure builders, and loaded installation health so the readiness report can describe real GitHub App behavior.maintainerCut) stay separated from miner rewards, and direct-PR-first stays the default unless issue-discovery intake is explicitly ready.RegistrationReadinessandGittensorConfigRecommendationOpenAPI schemas with the new fields.test/unit/registration-readiness.test.tscovering the required scenarios: ready repo, not-ready repo, issue-discovery-disabled recommendation, maintainer-cut readiness, missing-labels / missing-docs / missing-test-gate warnings, GitHub App permission/event warnings, lane variants, and a forbidden-public-language invariant.Why
Issue #38 needs Gittensory to explain whether a repo is ready to attract Gittensor miner work and to recommend a safe initial config with tradeoffs. The previous inline logic (from the registration polish gate) did not evaluate test-gate or queue health, did not describe GitHub App behavior, and was only exercised through integration tests. Extracting tested builders closes those gaps and makes the signal verifiable.
Validation
npx tsc --noEmit(typecheck) — passesnpx vitest run test/unit/registration-readiness.test.ts test/integration/api.test.ts test/unit/openapi.test.ts— 26 passednpm run docs:check— passesnpm run test:cigate runs on CI. (Locally on Windows, themcp-cli/local-branchsuites fail with a libuv child-process assertion that reproduces identically on the unmodified base branch — environment-only, unrelated to this change.)Safety
Closes #38